吐槽

下午刚dive into coding突然被人拉到一个case群里面让帮忙查一个看似普通的case，直接扰乱了coding的节奏，生气！并且经过很长一系列的排查最后发现竟然是由于一个让人哭笑不得的原因，生气Plus。

case经过

case大概是这样一个过程，我们对外提供的一个服务在投递告警信息，结果今天有一个人在进行开发的时候发现使用方式1投递之后利用方式2再投递消息会石沉大海，但是使用1|2这种方式同时发送是可以成功的。这问题听起来就很诡异。

那就开始排查吧：

于是使用tools自己尝试发送，结果成功了，无法复现case
在测试环境下启动服务，让其请求测试环境，case复现
阅读代码尝试定位问题，然而代码逻辑没什么明显的错误，并且线上使用这么久了没出过这个问题，推测代码问题可能性比较小
print大法好，定位出了问题

其实第一步和第二步对比就使得测试端有问题的概率变大了，经过输出一些关键变量，发现是由于方式1投递消息之后会将这个事件的时间戳更新，而这个时间戳是投递端指定的，一般情况下是投递端的当前时间，在使用方式2第二次投递的时候，由于间隔时间较短，此时进入了逻辑判定阶段，服务使用当前时间与事件上次更新时间进行对比，发现当前时间小于上次更新时间，于是直接返回了，因为正常情况下当所有服务器时间一致的情况下一定是当前时间大于上次更新时间的。然而此时客户端是从办公网络的Mac端发出的，同时Mac端比服务快15s，这就导致了上述问题的发生！！！

改进措施

大家都在服务器上开发不好吗？？？🤣
在服务最开始受到请求的时候应该对携带的时间戳做一次判定，如果大于当前时间将其置为服务器的当前时间

case联想

关于时区确实会导致很多奇怪的问题，比如说golang在从数据库读取或者存取的时候是会有一个时区丢失的问题的，同时如果使用python post json的方式把时间传输给golang的时候也会有一个时区丢失的问题，这个时候python需要在时间戳后面跟上+08:00来标示时区信息，否则会被换算成UTC时间哟。

之前还遇到的一个case问题更加奇葩，现象是crontab某些定时任务不会按照实际填写的时间运行，经过仔细排查发现，那种每隔一定时间运行的任务运行起来没问题，但是一旦牵扯到周五周六，几号这种他就会有问题发生，最后定位的原因也是奇葩，原来是系统安装之后默认时区是utc，此时运行了crond进程，这就导致了后续虽然系统时区修改正确了，但是cron一直是在utc时区下运行。。。这个case当时也是让人崩溃，解决方法也很简单直接重启cron就ok了。

囧

所以说，事件导致的case还是希望不要遇到的好🤣

转载请注明来源链接 http://just4fun.im/2018/04/26/case caused by time/ 尊重知识,谢谢:)